Early computers were programmed using machine-level language that performed rudimentary adding, subtracting, storing, and other similar basic features. While the use of machine-level language created very fast-executing applications, the amount of code required for even basic applications tended to be enormous. Moreover, machine-level language using binary code or hexadecimal code is not very intuitive for use by human to program with.
As computers advanced, high-level languages were developed that wrappered selected sequences of machine-level code into human-recognizable words for logically controlling the progress of the software application. Such abstraction makes use of interpreters, compilers, translators that process the high-level code into machine-executable object code. This concept of abstraction and wrappering has also been extended into high-level programming Most high-level languages allow for user-created functions, in which the user writes a block of code that represents the function and can call that functional code by referring to the function name in the main section of the program logic. Functions typically perform a designated task that is called during the execution of a particular program.
The concept of abstraction or wrappering comes from Object Oriented Programming (OOP). OOP is an evolutionary form of modular programming with more formal rules that allow pieces of software to be reused and interchanged between programs. The major concepts of OOP are encapsulation, inheritance, and polymorphism.
Encapsulation, i.e., abstraction or wrappering, refers to the creation of self- sufficient modules that contain the data and the processing methods that goes with the data. These modules are typically user-defined data types called classes. One instance of the class is referred to as an object. Classes are generally created in hierarchies Inheritance allows the knowledge, formatting, or processes in one class to be automatically passed down the hierarchy to other classes. This concept reduces the need for extensive programming when adding functions to existing, complex systems. Finally, polymorphism is the idea of allowing the same code to be used with different classes of data, resulting in more general and abstract implementations.
Application Development Environments (ADEs) often support OOP and employ components that are objects. ADEs are typically text-based, in which the developer enters code, graphics-based, in which the developer graphically manipulates screen objects to assemble an application, while the ADE automatically generates the underlying code to assemble the application. Using such graphics-based ADEs, developers may drag and drop components onto the development screen/area/surface in the process of designing and implementing various applications. A visual representation of the component is often displayed to the developer. The developer may then graphically manipulate the visual representation which places the objects within the application under design. Components typically have a list of properties that the developer can manipulate to affect the features and performance of the component. ADEs typically have an intermediate description of the visual representation. These intermediate descriptions will usually differ from environment to environment. The intermediate description typically identifies the type of component plus any parameters that have been changed by the developer. The parameters that are not altered by the developer usually remain at the default value.
Components often have user definable events that can be associated with scripting language or some native code which is triggered or executed when a certain event occurs inside the component. For example, a button component will typically have a ButtonPressed event that the developer can associate with come kind of logic that will execute.
Many ADEs also allow for user-created components. A component, much like an object, represents some encapsulated programmatic building block that may be used and reused throughout an application. Instead of requiring the user to rewrite the code each time the function or component is to be used, abstraction and wrappering allow for the function or component to be defined once but used many times, sometimes among many different programs, merely by referencing the name of the function or component and passing or setting parameters of the function/object. In general, the code underlying components is compiled before it is made available to the developer or is executed or interpreted at runtime depending on the type of code used. Functions are generally compiled or interpreted along with the code of the application that they are in. Functions and components may also become part of the underlying computer language. The code for these standard features is typically placed in standard or common libraries that are used either when the ADE is started for developing an application or an application is executed.
Functions and components are typically created defining properties that may be set by the developer in controlling certain aspects of the function or component, or providing the function or component with a piece of data used in performing its functionality. Some functions and components may be defined using properties that become known only on execution and only based on user input or other runtime- based information. In defining such runtime-oriented functions or components, the code for such “customization” is many times included in the source code of the application. A software company expends considerable resources in developing its software products. When code logic is exposed through the basic source code, the company's intellectual property becomes exposed to copying. Techniques have been developed to obfuscate code logic as much as possible; however, some ADEs or programming environments simply do not lend themselves to such obfuscation for some programming matters.
One difficulty faced in commercial software when code is not obfuscated, is having the software user make changes or modifications to the commercial software. Software manufacturers typically provide warranties or maintenance programs for their software. Therefore, difficulties may arise for the software manufacturers when trying to maintain software that has been modified by a third party. Moreover, the software company should not be responsible for the problems created solely because of the customer's modifications.
Creating new controls is generally reserved for programmers or developers who have significant programming experience. Typically, controls are defined or coded using lower-level languages, such as C++, SUN MICROSYSTEMS, INC.'s JAVA™, or MICROSOFT CORPORATION's C#™. Web designers who are generally used to simple, high-level HTML programming MICROSOFT CORPORATION's JSCRIPT™, NETSCAPE COMMUNICATIONS, INC.'s JAVASCRIPYF™, and the like, and will not typically be familiar or possibly even competent to program such components.